「當用腦袋在trace code時，最不爽的就是被其他雞毛蒜皮小事中斷，腦袋整個歸零後就歸巴豆火」
#TDD #IncrementalDelivery
大家應該都有過這種讓人火大的經驗吧！但在工作環境中，卻又很難避免被打擾，那自己能用什麼方式來減少這樣的負面影響呢？
最簡單的方式是，小量增量式的產出。例如切細工作。
當完成的時間點變多，自然處理臨時事務就比較有彈性。即使思緒被打斷，要重新再來的範圍小、成本低。
更完整與根本的作法，是透過TDD來做到增量式的產出，以及透過測試案例甚至living documentation來幫助記憶與理解。
所謂的小量、增量，多小算小到剛好？TDD的開發方式，基本上就是baby step, 每一個測試案例代表一種scenario, 每一個scenario都是從頭走到尾的一條路。每個新的scenario都會走過前面scenario 所建立的production code, 因此新的scenario只要完成與其他scenario不同的部分即可。
所以TDD每次要寫的部分只有一點點，如果再採取top-down方式設計production code, 那最後要完成的只有一堆private functions, 如果再搭配介面導向設計，那職責拆分後要寫的就更少了。
而整個feature/user story已經做到哪邊，完成哪些，透過可讀測試案例（更好的當然是living documentation）跟測試結果，一目了然。
我曾經抽空做一個案子，中間被中斷了四次，每一次都是間隔3週以上，（最後的專案程式碼大概快一萬行的規模），在每次回憶上次做到哪時，大概只需要3-5分鐘看一下specflow的scenarios跟context，就可以繼續往下寫。我都笑稱living documentation是我的儲思盆，而且是大家都看得到、看得懂的儲思盆。
TDD其實就像我常舉的一個比喻：需要完成的功能很大，就像要把水從井裏拉上來一樣。越大，就代表井越深。TDD就像幫你在井上多個卡楯，當你往上拉一點點後，就可以卡住，即使拉到一半沒力氣了，也不會前功盡棄。隨時準備好就可以再拉下一個循環。
這也是我常提到的「開發節奏」，一旦有節奏，就好安排時間，就會避免浪費，就會提高生產力，就會容易進入神馳狀態，就會很順。
寫程式可以這樣寫，不是讓人很愉快嗎？ :)
Search